約 2,593,524 件
https://w.atwiki.jp/kaneishi-shigekazu/pages/49.html
物の見方・考え方を変えねばなりません。 逆境にありながら、成功した人は、 1目標を持っていた。 2目標達成の手段を徹底的に考えた。 3手段が決まれば、それを死に物狂いで実行した。 という三条件を実行したのではないかと思います。 たくさんの人材紹介の会社が人材を売り込みにやってきます。 いずれも中高年の男性の売り込みです。 たまには女性もいます。 なぜ中高年かといいますと、バブルの崩壊後のリストラで、中高年が真っ先に外に出されたのです。 金石茂和（サービスマン養成所講師）
https://w.atwiki.jp/taxcutknowledge/pages/17.html
減税会立ち上げに便利なWEBサービスまとめ 有志による外部記事 シズオカちゃっぱさんのまとめ記事（Note） https //note.com/shizuokachappa/n/nb3385f215076 Twilog favolog Canva ペライチ Jimdo Stock AWS Lightsail Wordpressなどを手早く立ち上げられるクラウドサービス 規模に合わせて簡単にサーバ能力を上げることができるので、小規模から大規模まで便利に利用できます。 AWSについては@genzeidodoitsu で相談できます。 コメントフォーム 名前 コメント
https://w.atwiki.jp/kaneishi-shigekazu/pages/72.html
リサーチャーの世界には、「とんぼの目、ありの足、ウサギの耳」という言葉があります。 複眼でものを見、足を使い、耳をそば立てて情報を仕入れよ、ということを教えるものです。 しかし普通のビジネスマンがこんなことを守ろうったって、守れるものではありません。 若い頃この言葉を知り、年がいってからは後輩にしたり顔で教えもしました。 しかし肝心の本人は守れませんでした。 「意志薄弱」で「怠惰」で「注意力を欠く」フツーのビジネスマンには、このような「精神論」よりも「ちょっとした工夫」が大切です。 その一見何でもないちょっとした工夫。 ビジネスマンはいつも「知恵を出せ」と上から叱咤され、括弧の中に書いたような反発をします。 しかし、「知恵を出せ」にはなかなか答えられません。 金石茂和（サービスマン養成所講師）
https://w.atwiki.jp/testlink/pages/28.html
ユーザーマニュアル TestLink version 1.7 Copyright 2004 - 2007 TestLink Community Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The license is available in "GNU Free Documentation License" homepage. --- 翻訳 Testing Engineer s Forum (TEF) - ソフトウェアテスト技術者交流会 - 「TEF有志によるTestLink日本語化プロジェクト」部会 --- 1 一般情報 TestLinkはWebベースのテスト管理システムです。このマニュアルは、TestLinkを使用するために必要な操作手順、用語、構成などについて説明しています。インストール時に必要となる、システム要件、インストール手順、システム構成方法などは、インストールマニュアルをご参照ください。最新のドキュメントは、TestLinkフォーラム（www.teamst.org）または、SourceForge上のプロジェクトページ（testlink.sourceforge.net）からダウンロードすることができます。 （訳注 日本語で書かれた情報については http //www38.atwiki.jp/testlink/ または http //sourceforge.jp/projects/testlinkjp をご参照ください。） 1.1. TestLinkコンポーネントの全体構造 TestLinkの基盤となるコンポーネントは３種類あります。それは、テストプロジェクト、テスト計画、そしてユーザです。これ以外の全てのデータは、この基盤要素の関連もしくは属性となります。それではまず始めに、この文書およびソフトウエアテスト分野で使用される用語について定義します。 1.2. TestLinkで使用する用語 テストケースは、TestLink上でのテスト作業を表す最小単位であり、ステップ（アクション、シナリオとも呼ばれます）と実行結果を含んでいます。 テストスイートは、テストケースをグループ化するための単位です。これにより、テスト仕様を論理的に分割することができます。 テストスイートは、TestLinkバージョン1.6以前にコンポーネントやカテゴリと呼ばれていたものに対応します。 テスト計画は、テストケースを実行する時に作成されます。テスト計画は、ひとつまたは複数のテストプロジェクト上のテストケースから構成されます。テストケースには、製品ビルド、マイルストーン、テストの割り当て、そしてテスト結果が含まれます。 TestLinkの起動中は、必ず１つ以上のテストプロジェクトが存在しています。テストプロジェクトは、いくつものバージョンに更新されていきます。テストプロジェクトには、テストケースが登録されたテスト仕様、要件仕様、キーワードが含まれます。プロジェクトに参加するユーザには役割が設定されます。 TestLinkのユーザには、TestLinkの機能を使用して定義された役割が与えられます。詳しくはユーザ管理の章をご参照ください。図1はユーザの役割に関連する一般的な作業を表しています。 1.3. TestLinkを用いた作業の流れの例 1. 管理者がテストプロジェクト「ファーストフード」を作成し、「リーダー」権限をもったAdamと、「テスト主任」権限をもったBelaとい2. リーダーであるAdamが、ソフトウェア要件をインポートし、空のテストケースを作成します。 3. テスト担当者であるBelaが各テストケースのステップ(テストシナリオ)を記述し、テストスイートを用いてそれらを分類します。 4. Adamはキーワード「回帰」を作成し、10種類のテストケースにアサインします。 5. Adamはテスト計画「フィッシュ チップス」とビルド「フィッシュ 0.1」を登録し、キーワード「回帰」がアサインされたテストケースを登録します。 6. AdamとBelaはテストを実行し、5ケースで成功、1ケースで失敗、4ケースでブロックというように結果を記録します。 7. 開発者が新たなビルド「フィッシュ 0.2」を作成し、Belaが以前失敗もしくはブロックしたテストケースのみを実行します。これらのテストが成功したとします。 8. チームのマネージャもテスト結果を見たいことでしょう。ログインページでアカウントを追加できることを、管理者はマネージャに説明します。マネージャがアカウントを作成すると、デフォルトで「ゲスト」権限が与えられ、テストケースと実行結果を閲覧することができます。マネージャは、ビルド「フィッシュ 0.1」で問題があったことと、最終的に全てのテストケースが成功したことを確認できるでしょう。しかしながら、「ゲスト」権限しかないマネージャは、これらのデータを変更することはできません。 2. テスト仕様 TestLinkでは、テストケースの構造をテストスイートとテストケースに分解します。このレベルはアプリケーションを通して保持されます。 2.1. テストケースの作成 テスターは少なくともテストスイートとテストケースという構造に従わなければなりません。最初にテストプロジェクトに対して、ひとつか、それ以上のテストスイートを作成します。印刷に使用可能な説明を記述することができます。テストスイートは、別のテストスイートを含むことができます。 ユーザは、テストケースをコピーしたり、移動したりすることができます。 テストケースは次に示す部分を持っています。 タイトル：短い概要もしくは略号を含めることができます。(例：TL-USER-LOGIN) 要約：簡潔に、概要のようなもの ステップ：テストシナリオを記述します（入力操作）、事前条件や事後処理に関する情報を含めることもできます。 実行結果：確認事項や、期待結果に関して記述します。 テストケース番号はTestLinkによる自動採番で、ユーザが変更することは出来ません。 このIDは、テストプロジェクトに関わらず、テストケースが作成されるとき、システム全体でグローバルなカウンタが使用されているのを意味します。 テストケース - 有効属性 もし、複数のバージョンのテストケースが存在する場合、有効/無効を示す新しい属性があったほうが親切です。これは次のように使われます。 すべでのテストケースは、有効として作成されます。無効なテストケースのバージョンは「テスト計画へのテスト計画の追加」では、利用できません。これは、テストデザイナーにとっては便利な機能です。彼らはテストケースのバージョンを編集し、テスト計画で利用可能になった時に、完了したと判断して、ステータスを有効に変更することができます。 一度、テストケースのバージョンがテスト計画に関連付けられ、結果を持つと、無効にすることはできなくなります。 次のことに注意してください。テストプロジェクト名（この例では、toaster_x15)のそばの数字は２ですが、テストプロジェクトは３つのテストケースがあります。これは、テストケース１が無効なためカウントされていないからです。 2.2. テストケースの削除 テストケースとテストスィートはテスト計画からリーダの権限を持っている場合には削除することができます。この操作はテスト計画を最初に作成して、まだ結果が何もない場合には有効です。しかしながら、テストケースの削除はひもづくすべての実行結果を失うかもしれません。このことから、極端な警告がこの機能を使用するために推奨されています。 2.3. 要件との紐付け テストケースは、ソフトウエア要件、システム要件とｎ対ｎで関連付けられます。この機能は、テストプロジェクトで実現されています。ユーザは、テストケースと要件をメインメニューの要件の関連付けで割り当てることができます。 3.キーワード 3.1 キーワードを使う キーワードは、テストケースの分類において、ユーザにもうひとつのレベルを提供する為の機能です。 キーワードはテスト仕様の中で何らかの特性をもつテストケースのコレクションをサポートし、 あなたはそれを定義する為に使う事ができます。 例 回帰テストの為のセット 検討済みのテストケース 単一プラットフォームに向けたテストケース 3.2 キーワードの作成 キーワードはmgt_modify_key権限を持つユーザのみが作成できます。 この権限は、現在リーダーのみが持っています。ひとつ、あるいはキーワードの グループが作成されたら、ユーザーはそれをテストケースに割り当てる事ができます。 3.3. キーワードの割り当て テストケースへのキーワード割り当ては、キーワード割り当て画面[the assign keyword screen](一括)、 あるいはテストケース管理(個々)から行われます。 3.4. キーワードによるフィルタ ユーザがキーワードによってフィルタ可能なもの テスト仕様書からテストケースを探す。 テストスイートにテストケースのグループを加える。 テストスクリーンを実行する。 4. 要件に基づくテスト 4.1 イントロダクション テスターは、システムが仕様通りに作られていることを証明するために、 要件に基づくテストを行います。 全ての要件に対して複数のテストケースが設計されます。 テスト実行が終わると、テストマネージャーは、実行結果と要件の網羅度を報告します。 この情報に基づき、顧客とステークホルダーは、システムを 次のテストフェーズに移行、もしくは稼動させてもよいかを決定します。 システムが仕様通りに作られていることを保証するために、 テストマネージャーはリスクの組み合わせと要件に基づくテストを行います。 それは、システムが仕様通りに作られていることを、顧客とステークホルダー に見えるようにするためのものです。 要件に基づくテストの優位性： ・ リスクと要件を結びつけると、曖昧さや要件もれが明確になります。 ・ システムの最重要部分へ最初に焦点をあてられるので、優先度の高いリスクを カバーすることができます。 ・ 顧客やステークホルダーと同じ言葉でコミュニケーションできます。 そのため、テストプロジェクトの状態の報告がよりわかりやすくなるので もっとテストするか、リスクをとるか、を判断しやすくなります。 ・ リスクと優先度は納期の圧力のかかったテストプロジェクトでは交渉の対象になります。 リスクとは、テストプロジェクトで何をカバーする必要があって、何を 延期できるかということです。 リスクと要件に基づいたテストは、テストプロジェクトをより管理しやすくします。 顧客やステークホルダーとのコミュニケーションが改善されます。 テストマネージャはリスクと優先度に基づいたテストを始めます。 プロセスは合理化され、その結果、高品質の結果を得られます。 4.2. 有効性 機能を有効にするのはテストプロジェクトのレベルで行います。 すなわち、管理者はそのテストプロジェクトを有効にしなければなりません。 (メインウィンドウのテストプロジェクトのリンクを編集してください) そうしないとリンクは見えません。 これは利用者レベルを分けるためのものです。 最も一般的な役割では、要件を見ることはできても変更はできません。 詳細はユーザ管理の章を参照してください。 4.3. 要件仕様 要件はいくつかのシステム／ソフトウェア／ユーザ要件仕様に まとめられます。 要件文書の作成： 1. メインウィンドウの要件仕様をクリックします。 要件仕様リストのウィンドウが開かれます。 2. 文書を作成するために作成ボタンを押します。 3. 題名、スコープ、最終的なテストケースの数を書き換えます。 最後のパラメータは統計のために使われます。 もし、有効な要件文書があれば、それだけで使えますが、 入力した時点で TestLink の全ての要件が有効であるとは限りません。 デフォルト値 n/a は、仕様の中で現在までに使われた要件の 数を意味します。 検討中 begin 3. 題名、スコープ、最終的な要件の数を書き換えます。 最終的な要件の数は統計のために使われます。 全ての要件を登録しないうちにTestLinkを実行する場合に使うものです。 最終的な要件の数が設定されない場合には、現在登録されている要件の 数が使われます。 検討中 end 4. データベースにデータを追加するために作成ボタンを押します。 要件仕様リストのウィンドウの表の中に新しく作成した文書の題名が 表示されます。 5. 次の作業をするために文書の題名をクリックします。 要件仕様ウィンドウが開かれます。 各々の要件仕様は自分自身の統計値と 関係するデータが含まれたレポートを持っています。 "要件仕様" ウィンドウの全ての仕様は "印刷" ボタンを使って 印刷することができます。 管理者は定義ファイルの著作権と部外秘の表示で会社を定義できます。 4.4. 要件 個々の要件は、題名、スコープ(html 形式)、状態を持っています。 題名はユニークである必要はなく、最大半角100文字までです。 スコープパラメータはHTML 形式のテキストです。 状態は、有効(VALID)かテスト不可(NOT_TESTABLE)の値を持ちます。 テスト不可(NOT_TESTABLE)の要件は測定には含まれません。 要件はCSVファイルのインポートやTestLink インターフェース経由で 手動で生成、修正、削除できます。 4.4.1. 要件のインポート TestLink は２タイプの CSV 形式をサポートしています。 一つめのシンプルタイプは、各行に題名とスコープを含みます。 二つめの Doors からエクスポートするタイプでは、ヘッダと 選択された完全なフィールドを見つけようとします。 題名をインポートしてから比較して、衝突を回避します。 二つ目のタイプでは、以下の３つの方法が選択できます。 ・同じ題名の要件をインポートして更新する。 ・同じ題名の要件をインポートして新しいものを作成する。 ・同じ題名の要件はインポートしないようにする。 4.4.2. 要件とテストケースとの関係 テストケースはソフトウェア／システムの要件と多対多で関連づけられます。 すなわち、いくつものテストケースを一つの要件に割り当てたり、 複数の要件を一つのテストケースでカバーすることができます。 ユーザはメインウィンドウの割り当て要件リンク経由で 要件をテストケースに割り当てられます。 テスト仕様のカバレッジは、要件仕様ウィンドウの解析ボタンを 押すことで見ることができます。 4.4.3. 要件に基づく報告 「テストレポートとメトリクス」メニューに移動すると 要件に基づいた各種報告のリンクが表示されます。 現在の要件仕様の要件とテスト計画は、この報告で解析されます。 全テストケースの最新結果(テスト計画で有効な)は 個々の要件にも反映されます。 異なる結果が一つの要件に適用されるような場合は 優先順位の高い結果が適用されます。 優先順位は、上から失敗、ブロック、未実行、パスの順です。 要件カバレッジの例 要件は三件のテストケースでカバーされている。 これらの二つは現在のテストスイートに含まれている。 ビルド１では、一つはパスして、もう一つは未テストである。 現在の要件の全体の結果：未実行。 ビルド２で二つめのテストケースがテストされてパスした場合は 要件に適用される結果はパスとなる。 5. テストプロジェクト テストプロジェクトはTestLinkの基礎です。あなたの会社のリリース版テストプロジェクトは、時間がたつにつれてそれらの特徴や機能に変更がありますが、ほとんどが同じまま残ります。 テストプロジェクトは要件ドキュメンテーション、テスト仕様書、テスト計画、そしてキーワードを含んでいます。 5.1. 新規テストプロジェクトの作成 新規テストプロジェクトの作成は"管理者"権限を必要とします。各テストプロジェクトの名前は重複しないようにする必要があります。目視によりそれらを区別するために背景色をテストプロジェクトテンプレートに割り当てることができます。 新規プロジェクトを作成するとき注意すること たくさんのテストケースが孤立する、またはテストケースがシステムから削除されてしまうので、システムからテストプロジェクトを消すことは推奨しません。 テスト計画はある一定の時点におけるテストプロジェクトのテストを表します。その結果、テスト計画はテストプロジェクト上のテストケースから生成されます。 TestLinkはテストプロジェクトにCSVデータのインポートをすることをサポートしています。これは後述のインポートのセクションでより詳しく説明します。 5.2. テストプロジェクトの編集と削除 テストプロジェクトの編集は"管理者"権限を必要とします。ユーザは、テストプロジェクト名、背景色、要件管理機能の有効性の変更が可能です。 特権を持つユーザは、使われなくなったテストプロジェクトを無効にさせることもできます。これにより、無効なテストプロジェクトはトップナビゲーションバー上のリストに表示されなくなります(ただし、管理者の場合、このようなテストプロジェクトは、リストに * のマークがついた状態で表示されます)。 ユーザはテストプロジェクトの削除も可能です。この行為は、データベースからすべての関連データをも削除します。この行為は元に戻せません。削除の代わりに無効にすることを強くお勧めします。 6. テスト計画 テスト計画は、名称、説明、選出したテストケースの収集、ビルド、テスト結果、マイルストーン、テスターの割り当て、優先度の定義を含んでいます。 6.1. 新規テスト計画の作成 テスト計画はリーダー権限を持ったユーザにより、“テスト計画作成”ページ(“テスト計画作成”リンク)から作成できます。 テスト計画はテストケース実行の基礎です。テスト計画は、特定の時点においてTestプロジェクトからインポートされたテストケースで作られます。テスト計画はリーダー権限を持ったユーザのみ作成可能です。他のテスト計画からテスト計画を作成することも可能です。これで、ユーザは必要になった時点でのテストケースからテスト計画を生成します。パッチのためのテスト計画を作成するとき、これが必要となるかもしれません。ユーザがテスト計画を見るためには、適当な権限を持たねばなりません。権限は(リーダーにより)ユーザ定義/プロジェクト権限のセクションで割り当てることができます。ユーザにプロジェクトが見られないと言われたとき、このことを思い出してください。それくらい重要なことです。 6.2. ビルド リーダー権限を持ったユーザは、メインページの“ビルドの管理”リンクをたどることが可能です。 ビルドはソフトウェアの特定のリリースです。会社における各プロジェクトは、たぶん多くの異なったビルドで構成されています。TestLinkでは、実行はビルドとテストケースの両方で構成されます。もしプロジェクトにひとつもビルドを作成していなければ、実行画面はあなたに実行を許可しないでしょう。また、メトリクス画面は完全に空白になるでしょう。 現在、ビルドは編集できません。現存のビルドの表にある“ゴミ箱”アイコンをクリックすることでビルドを削除することができます。 6.3. テスト計画の削除 テスト計画はリーダー権限を持ったユーザにより削除できます。テスト計画を永久に削除すると、テスト計画と、テストケースやテスト結果など対応するデータのすべてとが、両方とも削除されます。これは特別なケースのためだけにとっておくべきです。 代わりに、テスト計画は同ページ上で無効にさせる(“メイン” ページの選択メニュー上に表示しないようにする)ことが可能です。 7. テスト計画に実装されているもの 7.1. 新規テストケースの追加 ステップと期待結果が含まれたテストケースが追加されます。 複数のテストプロジェクトからのデータを1つのテスト計画に追加することができます。キーワード(ナビゲーションシートで調整される)でテスト仕様書データをフィルターにかけることができます。 データがいったんテスト計画にリンクされると、それはチェック印でマークされるでしょう。既にテストケースをインポート済みであれば、再びそれをインポートしようとしても、それを無視するでしょう。 7.2. テスト計画からテストケースを削除する "テストケースの削除"ページから、リーダー権限を持つユーザは、テスト計画からテストケースとテストスイートを削除することができます。結果が保存されていないため、初回のテスト計画作成のときには、データの削除も役に立ちます。しかしながら、テストケースを削除することは、それらに関連しているすべての結果の損失をもたらすでしょう。したがって、この機能を使用するときには、極度に用心することをお勧めします。 左側のシートのツリーで、テスト計画における現在のテストケースだけを表示します。 7.3. 優先度 TestLinkはテストケースのオーナーシップと優先度を割り当てる能力をリーダー権限を持ったユーザに与えます。一般的なリスクはテストスイートレベルで行われます。 リスクレベルは low, medium, high そして重要度は 3, 2, 1 です。ユーザは優先度 A,B,C としてリスクと重要度(L1, L2, L3, M1, H2, M3, H1, H2, H3)の組み合わせを格付けすることができます。 リスク、重要度、オーナーシップ、および優先度を割り当てるのは、すべて任意であり、メトリクス画面では優先度Bをデフォルトとするでしょう。 7.4. テスト実行の割り当て テスト実行の割り当ては実行とメトリクス画面の両方に影響します。実行画面では、ユーザが割り当てられたことにより実行可能なテストケースをソートする機能を持っています。メインメトリクス画面には、テスト担当者が残しているテストケースを示すテーブルがあります。もしテスト担当者に割り当てられたテストケースが無ければ、デフォルトでは何もありません。 また、これらのメトリクスが有効にされるなら、テスト担当者はメインページにおいて、自分が実行したテストのメトリクスを見ることができます(インストールマニュアル参照)。 8. テストの実行 8.1. 概要 テストの実行は以下の条件が満たされると有効になります。 1.テスト仕様が作成された。 2.テスト計画が作成された。 3.テスト計画にテストケースが追加された。 4.ビルドが作成された。 5.テスト計画がテスターに割り当てられた(割り当てがされなければテスターはテスト計画のページに移動することはできません）。 メインページで要求されたテスト計画を選択して、 テストの実行 リンクをクリックします。左画面がツリー画面で表示され、テストケーススイートの設定ができます。ここではフィルタリングやビルドの定義ができます。 8.2. ナビゲーション ナビゲーション画面は フィルタ＆設定 とテストケーススイートが表示されたツリー型のメニューから構成されます。 8.2.1. テストケースのフィルタリング このテーブルでは洗練されたナビゲーションを通して、テストの実行前にユーザーがテストケースをフィルタリングできます。 テスタ テスタでテストケースをフィルタリングします。 キーワード キーワードでテストケースをフィルタリングします。テストケースの作成・編集・削除時かあるいは”キーワードの割り当て”で複数のテストケースにキーワードを割り当てます。キーワードはテストリーダにより作成・編集・削除できます。それぞれのテスタはキーワードの割り当てができます。 結果 結果でテストケースをフィルタリングします。「結果」はテストケースの実行時にそのビルドで何が発生したかを示します。結果は次のいづれかです。成功・失敗・ブロック・実行されてない。 8.2.2. テストビルドの定義 ビルドでテストケースをフィルタリングします。ビルドはテストの追跡をするための基本の構成になります。それぞれのテストケースは一つのビルドにつき一回実行されます。ビルドはテストリーダにより”新しいビルドの作成”ページで作成されます。 8.2.3. ツリー型メニュー ツリー型メニューは結果により色分けされてテストケースを表示します。 色付けされたメニュー デフォルトではツリーはドロップダウンボックスで選択されたビルドに対して、結果でソートされています。. ビルドによる色付けされたテストケースの例 ユーザはビルド2をドロップダウンボックスから選択し、"最近"チェックボックスを有効にしていません。ビルド2からのすべてのテストケースがその状況とともに表示されます。もしテストケース1がビルド2で成功しているならば、緑で表示されます。 ”最終結果”はメニューを最近のテスト結果により色付けします。 最近のテスト結果により色づけされたテストケースの例 ユーザはビルド2をドロップダウンボックスから選択し、"最近"チェックボックスを有効にしています。ビルド2からのすべてのテストケースがその最新状況とともに表示されます。もしテストケース1がビルド3で成功しているけれども、ユーザがビルド2を選択している場合には、緑で表示されます。 8.3. 実行 8.3.1. テストステータス テスト実行は、結果（成功、失敗、ブロック）を特定のビルドのテストケースに割り振リます。 ブロック されたテストケースは何らかの理由によりテストすることができません（例 構成の問題より機能的なテストを実行できないなど）。 8.3.2. テスト結果の挿入 テスト結果の画面は、適当なテストスイートもしくはテストケースをナビゲーション画面でクリックすることで表示されます。タイトルに現在のビルドとオーナーが表示されます。色づけされたバーはテストケースのステータスを示します。黄色はテストケースのテストシナリオを含みます。 Version1.5ではテスト仕様のテストケースが更新されたか削除されたかの表示機能はサポートされていません。 更新されたテストケース TL1.0.4ではフラグにより表示されましたが、Version1.6ではこの機能がありません。ユーザが適切な権限を持っていれば、メインページから"テストケースの更新”ページに移動することができます。 もし変更があった（新しいバージョンであるか、削除された）場合、ユーザがテストケースを更新する必要はありません。 9. カスタムフィールド カスタムフィールドはシステムレベルで定義をします。例）カスタムフィールドを同じフィールドＩＤで定義することはできません。カスタムフィールドを作成した後に、使用したいテストプロジェクトへ割り当てる必要があります。これはMantisモデルに基づきます カスタムフィールドはMantis(http //www.mantisbt.org/)とdotproject(http //www.dotproject.net/)の両方のモデルの機能を使って実装されています。 表示/変更属性 デザイン時の表示 カスタムフィールドがテストケース仕様で表示されます。 デザイン時の変更 ユーザはテストケース仕様でカスタムフィールドの値を割り当て・変更できます。 実行時の表示 カスタムフィールドはテストケースの実行時に表示されます。 実行時の変更 ユーザはテストケースの実行時にカスタムフィールドの値を割り当て・変更できます。 割り当てられた値は保存されます。 例 1. カスタムフィールド 追加備考 型 string テストスイートで利用できます。編集はテストケース仕様でのみできます。 ただしテスト実行時に表示されることで役に立てます。 デザイン時の表示 = YES デザイン時の変更 = YES 実行時の表示 = YES 実行時の変更 = NO 例 2. カスタムフィールド オペレーションシステム 型 list テストケースで利用できます。テストケースデザインでない場合には、テストケースの実行時のみ編集できます。 デザイン時の表示 = NO デザイン時の変更 = NO 実行時の表示 = YES 実行時の変更 = NO 10. テストレポートとメトリクス レポートとメトリクスはメインページの"結果"または"テストレポートとメトリクス"をクリックすることにより表示することができます。レポートとメトリクスは現在選択されているテスト計画を対象にしており、複数のテスト計画を対象にすることは現バージョンではできません。結果ページを表示する前にメインページで対象とするテスト計画が選択されているか確認してください。ユーザーに表示されるページは左枠と右枠のページで構成されています。 左枠のページからどのようなレポートを実行して表示するか選択することができます。 右枠のページには各レポート毎の説明と使用方法が表示されます。 左枠のページからは次の項目を設定することができます。 アクティブビルド "アクティブビルド"の項目を設定によって影響を受けるレポートは"アクティブビルドのメトリクス"レポートのみです。このレポートは設定されたビルドを元に現在のテスト計画の状態を表示します。 レポートフォーマット チャートを除く全てのレポートは次のいずれかの形式で表示させることができます： 1."normal" - ブラウザにレポートが表示されます 2."MS Excel" - Microsoft Excel形式でレポートがエクスポートされます 3."HEML Email" - ユーザーのメールアドレスにレポートが送信されます 現バージョンでは左枠から10種類のレポートを選択することができます。各レポートの目的や機能を以下に説明します。 10.1. アクティブビルドのメトリクス "アクティブビルド"に設定されたビルドの詳細な結果を表示します。このレポートは選択されたビルドで実行された結果のみ表示します。 レポートは結果を次の様なテーブルで表示します： 最上位のテストスイートごとの結果 ツリーの最上位のテストスイートごとに結果を表示します。テストケース数、成功、失敗、ブロック、未実行の合計と完了したテストケースの完了率が表示されます。完了したテストケースとは成功、失敗、ブロックのいずれかの結果が設定されたテストケースを指します。テストスイートに表示されている結果にはそのテストスイート内のテストスイートの結果も含まれています。 テストスイートごとの結果 ツリーの最上位のテストスイートだけでなく、テスト計画の全てのテストスイートごとにメトリクスを表示します。 キーワードごとの結果 テスト計画のテストケースに割り当てられているキーワードごとに結果を表示します。 10.2. 一般的なテスト計画のメトリクス このレポートはテストスイート、オーナー、キーワードごとにテスト計画の最新の状態を表示します。テスト計画の最新の状態とは、最も新しいビルドで実行されたテストケースで構成されます。例として、あるテストケースがいくつものビルドでテストされていた場合、最も新しいテスト結果が反映されます。最新のテスト結果を反映することは他の多くのレポートにも共通する概念です。最新のテスト結果は次のようにして決定されます。 1)テスト計画に反映されるビルドの優先順位はビルドの新旧によって決定します。より新しいビルドのテスト結果が古いビルドのテスト結果よりも優先されます。例として、あるテストケースのテスト結果がビルド1では"失敗"となっていたが、ビルド2では"成功"だった場合、最新のテスト結果は"成功"となります。 2)同じビルドでテストが幾度か実行された場合は、より新しいテスト結果が優先されます。例として、ビルド3がリリースされ、あるテスト担当者がビルド3のテスト結果を"成功"と設定し、後に別のテスト担当者が同じビルドのテスト結果を"失敗"と設定した場合、最新のテスト結果は"失敗"となります。 3)ビルドに対するテスト結果が"未実行"となっているテストケースは最新のテスト結果には反映されません。例として、ビルド1のテスト結果が"成功"となっておりビルド2のテスト結果が"未実行"となっていた場合、最新のテスト結果は"成功"となります。 次のようなテーブルが表示されます。 最上位のテストスイートごとの結果 最上位のテストスイートごとに結果を表示します。テストケース、成功、失敗、ブロック、未実行の合計と完了したテストケースの完了率が表示されます。完了したテストケースとは成功、失敗、ブロックのいずれかの結果が設定されたテストケースを指します。テストスイートに表示されている結果にはそのテストスイート内のテストスイートの結果も含まれています。 キーワードごとの結果 テスト計画のテストケースに割り当てられているキーワードごとに結果を表示します。 例： |キーワード|合計|成功|失敗|ブロック|未実行|完了率 [%]| |P3|1128|346|47|55|680|39.72| |P2|585|372|25|31|157|73.16| |P1|328|257|6|51|14|95.73| オーナーごとの結果 テスト計画のテストケースに割り当てられているオーナーごとに結果を表示します。オーナーが割り当てられていないテストケースは"未割り当て"という行に反映されます。 例： |テスト担当者|合計|成功|失敗|ブロック|未実行|完了率 [%]| |Dominika|579|217|34|47|281|51.47| |Mohammad|246|82|9|2|153|37.80| |未割り当て|35|19|0|1|15|57.14| |Ken|289|110|1|21|157|45.67| |Mallik|430|269|5|18|138|67.91| |Ali|227|123|28|13|63|72.25| |Mike|24|22|0|0|2|91.67| |Alex|272|155|1|36|80|70.59| 10.3. 全てのビルドの状態 全てのビルドのテスト結果を表示します。各ビルドごとにテストケース、成功、失敗、ブロック、未実行の合計とその割合が表示されます。テストケースを同じビルドで何度かテストしていた場合は、最も新しいテスト結果が反映されます。 10.4. メトリクスの抽出 このレポートはメトリクスの抽出条件を入力するページと抽出された結果を表示するページで構成されています。 抽出条件ページ： 抽出条件ページには4つの項目があります。各項目はデフォルトで全てのビルドとテストケースを抽出対象にするようアイテムが選択されています。抽出条件を変更することにより特定のオーナーやキーワード、テストスイート、ビルドの結果といった任意のレポートを作成することができます。 キーワード 任意のキーワードを選択することができます。デフォルトではキーワードは選択されていません。キーワードが選択されていない場合、キーワードが割り当てられているかに依存せず全てのテストケースが抽出対象になります。キーワードはテスト計画ページや、キーワード管理ページからアサインすることができます。テストケースにアサインされたキーワードは全てのテスト計画やテストケースのバージョンに反映されます。特定のキーワードについての結果を抽出したい場合はこの項目を変更してください。 オーナー オーナーを選択することができます。デフォルトではオーナーは選択されていません。オーナーが選択されていない場合、オーナーのアサインに依存せず全てのテストケースが抽出対象になります。現バージョンではオーナーが"未割り当て"のテストケースを検索することはできません。オーナーシップは"テスト実行の割り当て"ページやテスト計画でアサインすることができます。特定のテスト担当者の進捗を確認した場合はこの項目を変更してください。 最上位のテストスイート （複数選択することができます） 最上位のテストスイートを選択することができます。デフォルトでは全てのテストスイートが選択されています。選択されたテストスイートのみ抽出対象になります。特定のテストスイートについての結果を抽出したい場合はこの項目を変更してください。 ビルド （複数選択することができます） ビルドを選択することができます。デフォルトでは全てのビルドが選択されています。選択されたビルドによって実行されたテストケースのみメトリクスの抽出対象になります。例として、過去3つのビルドによってどのくらいのテストケースが実行されたか確認したい・・・等の場合はこの項目を変更してください。 キーワード、オーナーおよびテストスイートの選択によりテスト計画からテストケースの数が決定されます。この選択はテストスイートやテスト計画ごとのメトリクスを計算するために使われます。例として、オーナーに"Greg"、キーワードに"Priority 1"を設定し、全てのテストスイートを選択した場合はGregにアサインされたPriority 1のテストケースが抽出対象になります。レポートに表示されるテストケースの合計はこれら3つの項目により計算されます。 どのビルドを選択するかはメトリクスに表示されるテスト結果（成功、失敗、ブロック、未実行）に影響を与えます。詳細については前述されている"最新のテスト結果"の箇所を参照してください。 "クエリー送信"ボタンを押して抽出を開始し、結果を表示します。 抽出結果ページ： 抽出結果ページは次の項目を表示します： 1. レポート作成に設定された抽出条件 2. テスト計画全体の総計 3. テストスイートごとの総計（テストケース、成功、失敗、ブロック、未実行の合計）と実行結果。テストケースが複数のビルドで実行されていた場合、選択されたビルドの全ての実行結果が表示されます。しかし、テストスイートの概要は選択されたビルドの最新のテスト結果のみ表示します。 10.5. ブロック、失敗、実行不能テストケースレポート これらのレポートは現在のブロック、失敗、実行不能テストケースの全てを表示します。 “最近のテスト結果”ロジック(全体テスト計画メトリクスに基づいて表現された)は ブロック、失敗、実行不能と判断されたテストケースを採用しないようにします。 ブロック、失敗、実行不能テストケースレポートはユーザが統合バグトラッキングシステムを使用している場合 同類のバグを表示します 10.6. テストレポート 各々のビルドの各々のテストケースのステータスを見ます。 もしテストケースがなんども同じビルドで実行されたとすれば、 最新の実行結果を使うでしょう。このレポートの“?”は このビルドでは実行不能テストケースを知らせます。 大きいデータセットを使用している場合はより簡単に眼を通せるようにExcelフォーマットでこのレポートを エクスポートすることをお勧めします。 10.7. チャート このレポートページはブラウザにFlashのプラグインが必要になります。 Flashはhttp //www.maani.usから提供されており、結果を図式的なフォーマットで表示するために使用します。 “最近のテスト結果”ロジックはあなたの閲覧できる全部で４つのチャートで使用されます。 グラフはユーザを現在のテスト計画のメトリクスを視覚化し補助するために動画で表示されます。 提供している4つとは 1.全体のパス/失敗/ブロック/実行不能 テストケースの円グラフ 2.キーワードによる結果の棒グラフ 3.オーナーによる結果の棒グラフ 4.トップレベルスイートによる結果の棒グラフ 棒グラフの棒はユーザがパス、失敗、ブロック、実行不能ケースののおおよその数が見分けられる様に おのおの彩色されています。 10.8. 各々のテストケースのバグ総計 このレポートは全てのバグがファイルされた全体のプロジェクトの各々のテストケースを表示します。 このレポートはバグトラッキングシステムを接続している場合にのみ使用可能です。 12 ユーザ管理 12.1 アカウントの設定 すべてのユーザはアカウント設定ウインドウ(メニューバーの中の"Personal")から、 自分自身の情報を編集する事ができます。TestLinkはadministrator権限を持つ ユーザに対して、ユーザの作成、編集、削除を許可しますが、参照、ユーザパスワードの 変更は許可されません。もし、ユーザがパスワードを忘れた場合は、ログイン画面の 上部にあるリンクから、ユーザ名と登録したメールアドレスを入力すればそのアドレスへ パスワードが送付されます。 11.2. 役割と権限 TestKinkには6つの異なったデフォルトパーミッションレベルが用意されています。 これらの権限は管理者がアクセスできる”the user administration”で変更できます。 パーミッションレベルは下記のとおりです Guest テストケースとプロジェクトメトリクスの参照のみ行えます。 Test Executor 彼らに割り当てられたテストを実行する事のみ可能です。 Test Designer テスト仕様書および要求全てに働きかける事ができます。 Test Analyst テストの作成、編集、削除、およびそれらを実行する事ができます。 テスト計画の管理、テストプロジェクトの管理、マイルストーンの作成や権限の移譲は行えません。 Test Leader これまでの全ての権限を持ち、さらにテスト計画の管理、権限の移譲、マイルストーンの作成、 キーワードの管理が行えます。 Admininstrator これまでの全ての権限を持ち、さらにテストプロジェクトの管理が行えます。 注意 テスト計画に関連する機能は、もれなく作成済みのテス計画にアサインされる必要があります。 詳しくは、テスト計画のアサインの項をご参照ください。 11.2.1. 役割 TestLinkには規定の役割が存在します。管理者はシステムの中でデータを編集する適切な権限を付与します。それぞれのユーザに対して、これらの役割のひとつを割り当てます。下記のテーブルは、横の列にそれぞれの役割 (guest ,tester, senior tester, leader, admin)、次のカラムにそれぞれ異なる権限レベルを参照できます。これらのレベルは規定のものですが、自由に編集したり、新しい役割を定義する事もできます(熟練した管理者向け)。ユーザーテーブルは、役割の適切な権限レベルを指し示す外部キーを含んでいます。 Role|List of Rights|Permissions Guest|mgt_view_tc, mgt_view_key, tp_metrics|データの参照のみ Test Executor(Tester)|tp_execute,tp_metrics|テストの実行のみ Test Analyst(Senior Tester)|tp_execute, tp_metrics, tp_create_build,mgt_view_tc, mgt_modify_tc, mgt_view_key,mgt_view_req|テストの編集,テストの実行, ビルド生成 Test Designer|tp_metrics, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_req, mgt_view_req|テストと要求の編集 Test Leader|tp_execute, tp_create_build, tp_metrics, tp_planning, tp_assign_rights, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_key, mgt_view_req, mgt_modify_req|テスト計画に関するすべての権限, テストの編集と実行 Admin|tp_execute, tp_create_build, tp_metrics, tp_planning, tp_assign_rights, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_key, mgt_view_req, mgt_modify_req, mgt_modify_product, mgt_users|全ての事が可能. この役割だけが、ユーザとプロジェクトをメンテナンスできる Table 1 Role description 11.2.2. 役割の定義 次のテーブルは、役割の定義に使われたキーワードのリストです。 Right|Description mgt_view_tc|テスト仕様の参照 (data of Component, Category, and test case)| mgt_modify_tc|テスト仕様の編集 (create,modify,delete,order, move, and copy Components, Categories, and test cases) mgt_view_key|キーワードの参照 mgt_modify_key|キーワードの変更 mgt_modify_product|テストプロジェクトの生成、編集、削除 mgt_view_req|要求の参照 mgt_modify_req|要求の生成、編集、削除、紐付け Table 2 Test project related Rights Right|Description tp_execute|テストケースを実行する権限 (テスト結果の挿入) tp_create_build|ビルドを生成する権限 tp_metrics|メトリクスの参照 tp_planning|テストプランの生成、編集、削除、リスクとオーナーシップ、マイルストーン、テストスイートの割り当て tp_assign_rights|プロジェクト参照権限の割り当て Table 3 Test Plan related Rights 11.3. テスト計画の割り当て ユーザは割り当てられたテスト計画だけを見られます。 テスト計画の権限を得る為には、リーダー権限か、管理者権限を持つユーザが彼らに"ユーザ定義/プロジェクト権限"を通して、"テスト計画管理"にて権限を与える必要があります。 システムのすべてのユーザーが、新しくつくられたテスト計画を見るための権限をデフォルトで持っているというわけではありません（彼ら自身に権限を与えることの出来るテスト計画者を除いては） テスト計画の権限が0と言うことは、そのユーザはメイン画面にあるテスト計画ドロップダウンボックスのどんなテスト計画も見られないことを意味します。 テスト計画権限のテーブルにそれらはあります（すなわち、どのユーザがどのテスト計画を見ることが出来るかが分かります）。 このテーブルはユーザIDとプロジェクトIDが結合して作られます。 メインページには、ログインしたユーザに適切な権限があるかどうかチェックするコードが含まれます。 （そして許可されたプロジェクトを表示します。これを切ることは薦められません） 12. データのインポートとエクスポート TestLinkはデータを共有するいくつかの方法をサポートします。 項目 ファイルフォーマット あなたが得るもの キーワード CSV XML 全てのテストプロジェクトのキーワード テストプロジェクト XML 全てのテストスイートとテストケース あなたは割り当てたキーワードもまた、エクスポートするかどうか選ぶことができます。 テストスイート XML テストスイートの詳細、全てのテストケース、子となるテストスイートとテストケース あなたは割り当てたキーワードをエクスポートするかどうか選ぶことができます。 テストケース XML 2種類のエクスポートが可能です。 - 1つのテストケースだけ - テストスイートにある全てのテストケース あなたは割り当てたキーワードをエクスポートするかどうか選ぶことができます。 要件 CSV CSV DOORS（※） XML （※）このフォーマットではインポートしかサポートしていません。 テーブル4：項目はインポート/エクスポートの両方ができます。 制限：添付ファイルはエクスポートできません。 12.1. キーワードのインポート/エクスポート CSV形式の例 “キーワード;備考” Klyngon;Klyngon keyword notes Moon rocks;Moon rocks keyword notes XML形式の例 キーワード ?xml version="1.0" encoding="UTF-8"? keywords keyword name="Klyngon" notes ![CDATA[Klyngon keyword notes]] /notes /keyword keyword name="Moon rocks" notes ![CDATA[Moon rocks keyword notes]] /notes /keyword /keywords 12.2. テスト計画のインポート/エクスポート ユーザは計画の記述、テスト仕様とキーワードを含むテスト計画をインポート、 またはエクスポートすることができます。 次の２つの説明はツリーメニュー状データと同じデータのXMLファイルです。 ?xml version="1.0" encoding="UTF-8"? testsuite name="" details ![CDATA[]] /details testsuite name="Communications" details ![CDATA[ p Communication Systems of all types /p ]] /details testsuite name="Handheld devices" details ![CDATA[]] /details testcase name="10 G shock" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase testcase name="Gamma Ray Storm" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testsuite testsuite name="Subspace channels" details ![CDATA[ p Only basic subspace features /p ]] /details testcase name="Black hole test" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testsuite /testsuite testsuite name="Holodeck" details ![CDATA[]] /details testcase name="Light settings" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testsuite testsuite name="Propulsion Systems" details ![CDATA[]] /details testsuite name="Main engine" details ![CDATA[]] /details testcase name="Emergency stop" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testsuite /testsuite /testsuite 12.3. テストスイートのインポート/エクスポート キーワードを除いたテストスイートのXML出力例 ?xml version="1.0" encoding="UTF-8"? testsuite name="Handheld devices" details ![CDATA[]] /details testcase name="10 G shock" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase testcase name="Gamma Ray Storm" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testsuite キーワードを含むテストスイートのXML出力例 ?xml version="1.0" encoding="UTF-8"? testsuite name="Handheld devices" details ![CDATA[]] /details testcase name="10 G shock" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults keywords keyword name="Klyngon" notes ![CDATA[Klyngon keyword notes]] /notes /keyword /keywords /testcase testcase name="Gamma Ray Storm" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults keywords keyword name="Klyngon" notes ![CDATA[Klyngon keyword notes]] /notes /keyword keyword name="Moon rocks" notes ![CDATA[Moon rocks keyword notes]] /notes /keyword /keywords /testcase /testsuite 12.4. 単独のテストケース XMLファイルの例 ?xml version="1.0" encoding="UTF-8"? testcases testcase name="Black hole test" summary ![CDATA[ p This procedure must be done once a week, with this safety device disabled /p ol li X45HH /li li YY89-000-JI /li /ol ]] /summary steps ![CDATA[ p Preset bias to 0 /p p Enable strong long range /strong communications control /p p Simulate black hole interference /p ]] /steps expectedresults ![CDATA[ table width="200" cellspacing="1" cellpadding="1" border="1" caption Main Results /caption tbody tr td Spin value /td td 9.9 /td /tr tr td Opposite Angle /td td 18 rad /td /tr tr td nbsp; /td td nbsp; /td /tr /tbody /table ]] /expectedresults keywords keyword name="Moon rocks" notes ![CDATA[Moon rocks keyword notes]] /notes /keyword /keywords /testcase /testcases 12.5. テストスイート中のすべてのテストケース ?xml version="1.0" encoding="UTF-8"? testcases testcase name="10 G shock" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase testcase name="Gamma Ray Storm" summary ![CDATA[]] /summary steps ![CDATA[]] /steps expectedresults ![CDATA[]] /expectedresults /testcase /testcases 12.6. ソフトウェア要求仕様のインポート/エクスポート CSVファイルは“ドキュメントID, タイトル, 詳細”が含まれます。 CSVファイルの例 ENG-0001,Terrestrial Propulsor, ENG-0002,Main Deflector," p Main deflector bla, bla, bla. /p " XMLファイルの例 ?xml version="1.0" encoding="UTF-8"? requirements requirement docid ![CDATA[ENG-0001]] /docid title ![CDATA[Terrestrial Propulsor]] /title description ![CDATA[]] /description /requirement requirement docid ![CDATA[ENG-0002]] /docid title ![CDATA[Main Deflector]] /title description ![CDATA[ p Maindeflector bla, bla, bla. /p ]] /description /requirement /requirements Revision History # Description Date Author 0.x Documents for TL 1.5 and update for TL 1.6 2005 M. Havlat A. Morsing F. Mancardi 1.0 Converted to OO2 format; 2005/03/12 M. Havlat 1.1 Minor update; FIX 372, 352 2006/02/14 M. Havlat 1.2 Updated as draft for TL 1.7 2006/11/17 M. Havl?t 1.3 Removed TL 1.6 terms Added initial information about Custom Fields 2007/03/01 F. Mancardi 1.4 Added content and updated Franciscos “jumpstart_manual” and tl_file_format. General style cleanup and update. 2007/09/06 M. Havl?t
https://w.atwiki.jp/dnovels/pages/9.html
製本サービス 表紙にオリジナル画像を使用する際の注意点 オンデマンドフルカラー出力 RGB画像を指定しても、印刷時にCMYKに変換される PC画面と実際の印刷物では色合いの見た目が若干異なる場合がある 注文フォームでの入力項目 項目名 入力 備考 本タイトル 印刷用のタイトル 最大26字 著者名 印刷用の著者名 最大26字 連載 印刷を行う連載にチェックをつける 下書き保存中の連載も印刷可能 製本方式 現在は『くるみ製本』のみ 綴じ方式 現在は『右綴じ』のみ 仕上がりサイズ 『A5(W148×H210mm) 雑誌・教科書サイズ』『B6(W128×H182mm) 書籍サイズ』『A6(W105×H148mm) 文庫サイズ』 部数 印刷部数 表紙デザイン（表紙画像の選択） 『自作アップロード』『テンプレートから選択』 表紙デザイン（背表紙へのタイトル印刷） 印刷する場合はチェックを付ける 背表紙の厚さが5mm以上の場合のみ有効 表紙デザイン（表紙画像のアップロード） 自作アップロードをする場合に画像を指定する jpgファイルのみファイルサイズは10MB以内300dpi以上 表紙デザイン（裏表紙画像のアップロード） 自作アップロードをする場合に画像を指定する指定しない場合、背表紙色で塗られる jpgファイルのみファイルサイズは10MB以内300dpi以上 背表紙色 色を指定 背表紙文字色 色を指定 背表紙フォント 『明朝体』『ゴシック』 名前 コメント
https://w.atwiki.jp/kaneishi-shigekazu/pages/61.html
リスクとは、一般的に 予想通りにいかない可能性、危険嵐などと解釈されます。 これを企業経営におけるリスクという観点で考えると、 経営に損失を与える危険性、ということになるでしょうか。 つまりリスクとは、実際に起きた事象ではなく、未然に防ぐべき危険性の総称ということです。 「クレーム対応」「トラブル対応」について取り上げています。 クレーム対応とトラブル対応は広く考えるとリスクの一種でもあります。 金石茂和（サービスマン養成所講師）
https://w.atwiki.jp/kaneishi-shigekazu/pages/50.html
雀荘でマージャンをするとき、お金を賭けてやる人がいる。 しかし、これはれっきとした賭博罪にあたる。 逮捕起訴されれば、50万円以下の罰金または科料が科せられるのだ。 ここで誰もが気になるのが、いったい1年間に何回やったら「常習」になるのか、ということだろう。 これまでの判例からすると、たとえサラリーマンでも、同じ店で半年間に20回以上賭けマージャンをしていると賭博の常習者とみなされるようだ。 金石茂和（サービスマン養成所講師）
https://w.atwiki.jp/tikita/pages/215.html
SAIで群集の影（ハイライト）塗りマニュアル（Ver.５) 047系解説テキスト／5人ダンスまとめVer.6.xls ↑を元に作業を進めてください。必要に応じて改変してください。 群集パレットを使用する1シーン（または一連の動き）はSAIをメインで使用し、複数の人間で分業して塗り上げていくことを前提にしています。 ※ここでは便宜上群集シーン＝５人ダンスシーン及び047系、という意味で使っています ※このまとめのやり方で誰が塗っても問題が起きないように、気がついた方は随時修正をいれてください。 ※β2(d)からsai形式保存の仕様が変更になり、 β2(d)以降で保存した.saiファイルはそれ以前のバージョンでは読めなくなりました。 β2(d)以降のバージョンならどのバージョンで保存したファイルも読み込むことができるので、必ず β2(d)以降のバージョンを使用してください！ →ペイントツールSAI SAIは開発中のソフトですので最新バージョンが常にベストとは限りません。使用期限更新版を上書きする場合はそれを念頭に置いて、以前のバージョンをコピーしてとっておく等の対策を各自しておいてください。 目次 分業工程の大まかな流れ 分業工程工程０．20枚を作業がしやすいようにキー線画を決める 工程１. キー線画のみベース塗り 工程２. SAIでキー線画の境界線を描き、影塗りをする（１）境界線を描く （２）白目、瞳の中をフリーハンドで塗る （３）バケツで影とハイライトを塗る （４）細部を手直し （５）次の境界線を描く （６）（３）と同じ要領で塗る （７）１枚目の「目」レイヤーセットをコピーして使いまわす （８）GIFアニメでチェック 工程３． 2、3、4枚目のベース塗りをするベース塗り 工程４． 2、3、4枚目の境界線作成（影割り）と影塗りをする（１）境界線を描く（影割り） （２）影塗り 工程５． 20枚分全てのデータが揃ったら最終調整をして確認→PNG化 群集ｼｰﾝの影塗り分業をSAIで行う長所と短所◎ 長所 ◎ ◎ 短所 ◎ フォトショップ、GIMPとの連携問題 分業工程の大まかな流れ 例として『全20枚の群集シーンを分割し、そのうちの1枚目～5枚目を作業する』とします。 工程 作業内容 作業者 ０． 20枚を作業がしやすいようにキー線画を決める ★最終調整する職人が中心となって考える １． キー線画のみベース塗り ★塗り初心者でもOK、使用ソフトもPSD保存ができれば何でもOK ２． SAIでキー線画の境界線を描き、影塗りをする ★最終調整する職人が作業 ３． 2、3、4枚目のベース塗りをする ★塗り初心者でもOK ４． 2、3、4枚目の境界線作成（影割り）と影塗りをする ★中割経験のある職人ならできそうだが、影の調整の難易度はやや高め ５． 20枚分全てのデータが揃ったら最終調整をして確認→PNG-24(αチャンネル透過)化 ★工程２の最終調整する職人が担当PNG化は★画像処理職人に依頼しても可 この５工程に作業を分けて分業していきます。 以下より詳しいやり方の説明です。 分業工程 工程０～５までの詳細を説明します。 工程０．20枚を作業がしやすいようにキー線画を決める 作業者：最終調整する職人のみ 使用ソフト：PSDで保存ができれば何でもOK キー線画を1、5、9、13、17、20枚目の6枚とすると、1～5、5～9、9～13、13～17、17～20の5つのグループに分割できる。 キー線画とキー線画の間の線画が1～3枚になるようにグループ分けする 工程３、４の職人が作業しやすいようにするため、分割した各データの最初と最後に見本となる塗りと境界線がある 前のグループとかぶっている塗りがあることで、グループ毎のつなぎもスムーズになる 分割は実際の動作や割りの枚数とも関連するので、いつもこの例のようにできるかはわからないが、分業をスムーズに進めるためには上記の３点は押さえる必要アリ。 元のサイズ 工程１. キー線画のみベース塗り 作業者：塗り初心者でもOK 使用ソフト：PSDで保存ができれば何でもOK １ファイルで線画５枚分までとする(SAIのレイヤー枚数上限(256枚)の関係上) 瞳レイヤーは必ず一番上に作ること アンチエイリアスを使用せずに塗ること 二値化線画は影塗りでも使うので、必ず残しておく！ 線画が非常に細かいのでﾌｫﾄｼｮ等のパスを使ったベース塗りは、できれば避けたほうが良い（塗り残しが多発しやすい） 元のサイズ ↓ ↓次の作業者へ.saiまたは.PSD形式でデータを渡す ↓ 工程２. SAIでキー線画の境界線を描き、影塗りをする 作業者：最終調整する職人のみ 使用ソフト：SAI この作業をする人が最終的に20枚全体の調整役となるので、ここで一気に全部のキー線画の境界線を描き、影塗りも行う。ただし１ファイルでキー線画５枚までとする。 ベース塗りデータがレイヤーセットを使用していない状態で受け取った場合は、やりやすいようにレイヤーセットを使って整理していく。 まずは1枚目から作業開始 （１）境界線を描く 境界線はパスで描くので保存形式は.saiに変更 境界線を描く時は以下の状態で描くこと。この状態で描くと後で修正しなくても選択範囲の閉じ漏れはまず起こらない通常線画は非表示で二値化線画を表示 筆圧はなし 境界線の太さは1.0、 合成モードはカラー二値化 不透明度は40％ ※境界線は最終的には非表示にするので黒以外なら何色でもOK ※細かくなるが肌影の境界線も描くこと ※垂直・平行に近い曲線は稀に切れてしまうことがあるので、その時は制御点をいじると再び繋がる （２）白目、瞳の中をフリーハンドで塗る 群集は線画が細かく、こういった部分は境界線が描けないのでフリーハンドで塗る鉛筆・エアブラシツールのどちらを使用してもいいが、ブラシの形状は必ず一番右の最もボケの少ないものにする。消しゴムも同様。 白目レイヤーは瞳レイヤーの直下に作ること 瞳ハイライトは瞳ベース塗りレイヤーとは別レイヤーに塗った方が無難「下のレイヤーでクリッピング」（グループ化機能）を活用すると便利 瞳と白目をひとつのレイヤーセットに入れ、名前を「目」にしておくこの後「目」レイヤーセットをコピーして使いまわしていく 肌影のフリーハンド塗りは基本は不可とする （３）バケツで影とハイライトを塗る 各ベース塗りレイヤーは必ず「透明部分の保護」をする 二値化線画と二値化境界線を表示二値化線画が無かった場合は作っておく（やり方はSAIでベース塗り参照） バケツツールの設定は領域抽出モードが「色差が範囲内の部分」 色差の範囲は±25 領域抽出元は「キャンバス」にチェック アンチエイリアスもチェック バケツツールでベース塗りレイヤーに直接塗る鋭角部分や線が込み入っている部分は拡大すると1、2ドットの塗り残しがあることが多いので、塗り残しの無いようにバケツで塗っておくこと。そういった部分の手を抜かないことによって綺麗な鋭角が表現できる。間違って境界線部分をクリックすると境界線の下が塗られてしまうので、充分拡大（500～800％程度）してからマウスで行うとやりやすい。 ※いきなり境界線を描くのはイメージがつかみにくいという人は、先にフリーハンドで影塗りをして、それを元に境界線を描いてもOK。フリーハンド塗りの際は修正しやすくするため、ベース塗りレイヤーとは別レイヤーに「下のレイヤーでクリッピング」（グループ化機能）を活用して影を塗ること。 （４）細部を手直し 基本的には（３）のやり方でかなり綺麗に仕上がるが、稀に鋭角な部分に穴が開いたような塗り残しが起きることがあるので、境界線を非表示にして確認し、極細い鉛筆ツールで修正。ただしやり過ぎない事。 50％に縮小した時わからない程度ならスルーでOK。 （５）次の境界線を描く 次の境界線を描く時は、1枚目（または似たポーズ）の境界線をコピーし、それを元に描いていくと通しで見た時のブレが防げる（線画の中割と同じ）。 「マクロ変形制御点ON/OFF」と「ストロークマクロ変形」を活用すると更に線の細かいヨレが防げる。 （６）（３）と同じ要領で塗る （７）１枚目の「目」レイヤーセットをコピーして使いまわす サイズ変更・自由変形・回転をするとエッジがぼけたり変色したりするのでやや注意が必要。 白目や瞳はとても小さいため変色等も目立ちにくいので、少々の変形ぐらいなら大丈夫 明らかに顔の向きが違う場合は潔く新たに塗った方が無難 ただし瞳ハイライトの配置がズレると意外に目立つので注意！ 以降これを繰り返していく。 途中でレイヤー枚数上限に引っ掛かるかもしれないので、レイヤーやレイヤーセットを増やし過ぎないように。 （８）GIFアニメでチェック チェック終了後、１枚目の影をフリーハンド塗りしていた場合は、「目」レイヤーセット以外バケツ塗りでやり直しておくこと。 ↓ ↓ 次の職人へ.sai形式でデータを渡す ↓ 工程３． 2、3、4枚目のベース塗りをする 作業者：塗り初心者でもOK 使用ソフト：SAI １枚目と５枚目以外は担当外なので削除 2、3、4枚目のPNG線画を1枚目と5枚目の間に追加する ベース塗り 二値化線画でバケツ塗り 線画と各キャラごとベースカラー分のレイヤーを準備二値化線画の作り方はSAIでベース塗りを参照 バケツツールの設定は領域抽出モードが「色差が範囲内の部分」 透明とみなす範囲は後で影塗りするときに±25にしないといけないので±25に設定（実際はこの作業での数値はほとんど関係ない模様） 領域抽出元は「キャンバス」 アンチエイリアスはチェックを外す 線画の色に近い背景、ムラのある背景は作業に支障をきたすので絶対に不可鋭角部分、線の込み入った部分の塗り残しに注意 ※各ベース塗りレイヤーは必ず「透明部分の保護」をする ↓ ↓次の職人へ.sai形式でデータを渡す ↓ 工程４． 2、3、4枚目の境界線作成（影割り）と影塗りをする 作業者：中割経験者ならできそうだが、影の調整の難易度はやや高め 使用ソフト：SAI （１）境界線を描く（影割り） 工程２の（１）と（５）の要領で２～４枚目の境界線を描いていく （２）影塗り 工程２の（３）（４）（７）の要領で作業する。バケツのアンチエイリアスのチェックを入れるのを忘れずに！ 塗りあがったらGIFアニメでチェック。スレで指摘があれば修正していく。なるべく境界線から修正するのが望ましい。 ↓ ↓ 工程２の作業者へ.saiでデータを渡す ↓ 工程５． 20枚分全てのデータが揃ったら最終調整をして確認→PNG化 作業者：最終調整する職人、画像の縮小・透過作業は画像処理職人に依頼も可 使用ソフト：SAI、その他 最終調整は作業者のやりやすいようにやればOKです。微妙な修正ならフリーハンド修正の方が楽かもしれないです。後悔しないように忘れずに.saiでの最終保存を行いましょう。 最終調整が終わったら 境界線は非表示（または削除） 二値化線画は表示したまま （※1） レイヤーセットを統合してからPSDで保存 （※2） フォトショップまたはGIMPで背景透過のPNG-24で保存 （※3） （※1）SAIでベース塗りをすると二値化線画の下には色が塗られていないため 通常線画だけだとその部分が微妙に半透明化してしまう 必ず二値化線画を表示したままにしておくこと 線画の下にベース色が入っていて更に二値化線画を表示しても特に害はないので ベース塗りの状態がどうであっても二値化線画は表示のままで！ （※2）GIMPはレイヤーセット機能やグループ化機能がなく、 それらが使われたデータを開くと全て解除されてしまうし、 フォトショップはバージョンによってレイヤーセット機能に差があって 開けたり開けなかったりするため SAIでPSD保存する段階でレイヤーセットは統合しておく 統合の仕方は１枚分の線画・塗りの入った最上層レイヤーセットを一発で統合する 元のサイズ （※3）SAIは縮小があまり得意ではないようなので、縮小はフォトショップかGIMPで行う この作業は画像処理職人に依頼しても可 以上で分業は終了です。 状況により工程３と４の作業を同じ人が行ってもいいと思います。 一見境界線やバケツ塗りの設定が面倒そうですが、最初に設定してしまえばいじる必要はほぼ無く、いじるのはベース塗りと影塗りでアンチエイリアスを切り替えるだけです。 群集ｼｰﾝの影塗り分業をSAIで行う長所と短所 ◎ 長所 ◎ 製品化前のテスト版を無償で使用できる パス線が描ける スレに使い慣れた人が多い……機能面での質問がスレであった時答えられる人が多い→作業者が不安になりにくい 扱いが比較的容易なので初めて使う人も覚えやすい 多階層レイヤーセットを作ることが可能……頻繁に前後の絵を見て比較するので、レイヤーセット機能がないと確認の度に数十枚のレイヤーをさかのぼり、表示非表示を切り替えなければならないが、レイヤーセットでレイヤーをまとめてしまえば簡単楽チン→精神的負担が大幅に軽減 グループ化機能（下にあるレイヤーの透明部分をマスクとして扱える機能）がある……「下のレイヤーでクリッピング」という機能がこれにあたります。フリーハンド塗りの時に非常に便利です。 ◎ 短所 ◎ レイヤーが256枚までしか作れない。レイヤーが256枚以上あるデータも開けない（レイヤーセットもレイヤー1枚としてカウントされる） 対策→→作業者の負担、データの重さ等を考えても基本的に１ファイルで線画５枚以下、 ５人のシーンは前列と後列に分けてキャラ数は３人までが理想です 線画５枚で、瞳など一部を除き影塗りをベース塗りレイヤーに直接塗れば 256枚以内に収めることができます それでも無駄なレイヤーを作っている余裕はあまりありません パスを選択範囲に変換することが出来ないので、多少塗り残しが起きる可能性がある 対策→→バケツ塗りの時、鋭角部分や線が込みいっている部分の1、2ドットの塗り残しを 拡大してきちんと潰しておけば、後の手直しはほぼ必要なくなります 実験ではバケツ塗り後のフリーハンド修正一切ナシで綺麗に仕上げることに成功しています フォトショップ、GIMPとの連携問題 多階層レイヤーセットを活用することが前提となっているので、他のソフトととの連携作業が難しい 二値化線画でアンチ有塗りという組み合わせでこの仕上がり状態になるのはSAIのクセのようなので、工程４の影塗りをSAI以外のソフトでやると仕上がりが変わってしまう可能性がある？ パス情報の共有ができない ―→ 修正の可能性を考えると、最後にPSD化する直前までパス情報は生かしておきたい 作業のわかりやすさと仕上がりを優先すると、工程２～５の作業は一貫してSAIで行うことにした方が良いのではないかと考えています。各ソフトユーザーごとに担当シーンを棲み分けした方が結果的に職人さんの負担も少なくなりそうです。
https://w.atwiki.jp/legendworld/pages/96.html
安藤君サービスとは、安藤君とドリャイアが、自分の言ったチャットでの発言を 削除してくれるサービスのことである。 概要 Legend worldチャットＡＤＳで、何か失言や間違った発言などをした場合、 「安藤君」とチャットに入力することで、自分が言った直前の発言を、安藤君に消してもらうことができる。 また「クリア」とチャットに入力することで、自分が今まで発言してきた言葉を一気に安藤君に消してもらうことができる。 消してもらうと「○○が安藤君とドリャイア君をこき使いました」 （「クリア」の場合「○○さんは安藤君とドリャイア君にコメントをすべて消させました」）と、 表示され、自分の発言が削除される。 （チャット上での発言は消えても、管理者ページからの過去ログでは、消されずに履歴が残るようになっており、 たとえ、発言をすぐに削除したとしても、管理者にはお見通しなのである。注意されたし。） 微妙な違い ＵＮＤＯ機能の場合は、使用者の名前は呼び捨てされるが、 クリア機能の場合は、「さん」づけされる。 こき使うときは安藤君の態度も悪いということ。 サービス使用による代金（ジョ－ク） 自分の直前のコメント削除（ＵＮＤＯ機能）使用料金：１０００円 自分のすべてのコメント削除（クリア機能）使用料金：５０００円 また、これに関しては、関連項目安藤君の借金を参照されたし。 関連項目 安藤君 ドリャイア 安藤君の借金 安藤君の部屋 安藤家 安藤盟
https://w.atwiki.jp/kaneishi-shigekazu/pages/30.html
金銭欲を利用する意欲づけ この意欲づけは、主として、「仕事中心のマネジメン♪」でつかわれる。 金銭による意欲づけは、働くものにとって基本的な誘因だが、それだけでは十分な成果は期待できない。 仕事から離れたところの意欲づけ 「人間中心のマネジメント」で採られたもので、好きなクラブ活動を時間外に行なわせ、センチメントを満たすことにより、意欲を引き出そづとするものである。 これは今日ではあまり効果が期待できなくなった。 金石茂和（サービスマン養成所講師）